As is known, the art and science of three-dimensional (“3-D”) computer graphics concerns the generation, or rendering, of two-dimensional (“2-D”) images of 3-D objects for display or presentation onto a display device or monitor, such as a Cathode Ray Tube (CRT) or a Liquid Crystal Display (LCD). The object may be a simple geometry primitive such as a point, a line segment, a triangle, or a polygon. More complex objects can be rendered onto a display device by representing the objects with a series of connected planar polygons, such as, for example, by representing the objects as a series of connected planar triangles. All geometry primitives may eventually be described in terms of one vertex or a set of vertices, for example, coordinate (X, Y, Z) that defines a point, for example, the endpoint of a line segment, or a corner of a polygon.
To generate a data set for display as a 2-D projection representative of a 3-D primitive onto a computer monitor or other display device, the vertices of the primitive are processed through a series of operations, or processing stages in a graphics-rendering pipeline. A generic pipeline is merely a series of cascading processing units, or stages, wherein the output from a prior stage serves as the input for a subsequent stage. In the context of a graphics processor, these stages include, for example, per-vertex operations, primitive assembly operations, pixel operations, texture assembly operations, rasterization operations, and fragment operations.
In a typical graphics display system, an image database (e.g., a command list) may store a description of the objects in the scene. The objects are described with a number of small polygons, which cover the surface of the object in the same manner that a number of small tiles can cover a wall or other surface. Each polygon is described as a list of vertex coordinates (X, Y, Z in “Model” coordinates) and some specification of material surface properties (i.e., color, texture, shininess, etc.), as well as possibly the normal vectors to the surface at each vertex. For 3-D objects with complex curved surfaces, the polygons in general must be triangles or quadrilaterals, and the latter can always be decomposed into pairs of triangles.
A transformation engine transforms the object coordinates in response to the angle of viewing selected by a user from user input. In addition, the user may specify the field of view, the size of the image to be produced, and the back end of the viewing volume to include or eliminate background as desired.
Once this viewing area has been selected, clipping logic eliminates the polygons (i.e., triangles) which are outside the viewing area and “clips” the polygons, which are partly inside and partly outside the viewing area. These clipped polygons will correspond to the portion of the polygon inside the viewing area with new edge(s) corresponding to the edge(s) of the viewing area. The polygon vertices are then transmitted to the next stage in coordinates corresponding to the viewing screen (in X, Y coordinates) with an associated depth for each vertex (the Z coordinate). In a typical system, the lighting model is next applied taking into account the light sources. The polygons with their color values are then transmitted to a rastenzer.
For each polygon, the rasterizer determines which pixels are positioned in the polygon and attempts to write the associated color values and depth (Z value) into frame buffer cover. The rasterizer compares the depth (Z value) for the polygon being processed with the depth value of a pixel, which may already be written into the frame buffer. If the depth value of the new polygon pixel is smaller, indicating that it is in front of the polygon already written into the frame buffer, then its value will replace the value in the frame buffer because the new polygon will obscure the polygon previously processed and written into the frame buffer. This process is repeated until all of the polygons have been rasterized. At that point, a video controller displays the contents of a frame buffer on a display one scan line at a time in raster order.
With this general background provided, reference is now made to FIG. 1, which shows a functional flow diagram of certain components within a graphics pipeline in a computer graphics system. It will be appreciated that components within graphics pipelines may vary among different systems, and may be illustrated in a variety of ways. As is known, a host computer 10 (or a graphics API running on a host computer) may generate a command list through a command stream processor 12. The command list comprises a series of graphics commands and data for rendering an “environment” on a graphics display. Components within the graphics pipeline may operate on the data and commands within the command list to render a screen in a graphics display.
In this regard, a parser 14 may receive commands from the command stream processor 12 and “parse” through the data to interpret commands and pass data defining graphics primitives along (or into) the graphics pipeline. In this regard, graphics primitives may be defined by location data (e.g., X, Y, Z, and W coordinates) as well as lighting and texture information. All of this information, for each primitive, may be retrieved by the parser 14 from the command stream processor 12, and passed to a vertex shader 16. As is known, the vertex shader 16 may perform various transformations on the graphics data received from the command list. In this regard, the data may be transformed from World coordinates into Model View coordinates, into Projection coordinates, and ultimately into Screen coordinates. The functional processing performed by the vertex shader 16 is known and need not be described further herein. Thereafter, the graphics data may be passed onto rasterizer 18, which operates as summarized above.
Thereafter, a Z-test 20 is performed on each pixel within the primitive. As is known, comparing a current Z-value (i.e., a Z-value for a given pixel of the current primitive) with a stored Z-value for the corresponding pixel location performs a Z-test. The stored Z-value provides the depth value for a previously rendered primitive for a given pixel location. If the current Z-value indicates a depth that is closer to the viewer's eye than the stored Z-value, then the current Z-value will replace the stored Z-value and the current graphic information (i.e., color) will replace the color information in the corresponding frame buffer pixel location (as determined by the pixel shader 22). If the current Z-value is not closer to the current viewpoint than the stored Z-value, then neither the frame buffer nor Z-buffer contents need to be replaced, as a previously rendered pixel will be deemed to be in front of the current pixel. For pixels within primitives that are rendered and determined to be closer to the viewpoint than previously-stored pixels, information relating to the primitive is passed on to the pixel shader 22, which determines color information for each of the pixels within the primitive that are determined to be closer to the current viewpoint.
Optimizing the performance of a graphics pipeline can require information relating to the source of pipeline inefficiencies. The complexity and magnitude of graphics data in a pipeline suggests that pipeline inefficiencies, delays, and bottlenecks can significantly compromise the performance of the pipeline. In this regard, identifying sources of aforementioned data flow or processing problems is beneficial.